For mobile communications systems it is generally required that a mobile terminal first attaches to/registers with the network before being able to receive desired services. This attachment/registration usually comprises authentication and authorization of the mobile terminal in the network and is often referred to as “network attachment”. For each mobile terminal attaching/registering with the network context state information and signaling messages are generated at the network entity handling the network attach. So obviously each mobile terminal creates some load at this entity. Of course there is an upper bound for the load a specific network entity can process, resulting in an upper bound regarding the number of mobile terminals such an entity can handle. Therefore, it might be required to spread the load caused by the mobile terminals across several network entities.
Generally mobile communications systems can be split into logically separated parts providing dedicated functionalities. These parts are usually called core network (CN) and access network (AN) with several access nodes. Particularly for wireless mobile communications systems the latter part is usually referred to as radio access network (RAN).
Typically the network entities handling the network attach functionality are located in the core network of the mobile communications system. Entities in the radio access network and core network utilize defined interfaces to communicate between each other. In order to allow a distribution of the load caused by the mobile terminals across several core network entities, each radio access network entity handling the radio connection with the mobile terminal has to have a relation (i.e. interface) to a plurality of core network entities. As there are several radio access network entities deployed in a mobile communications system, this results in a many-to-many relation between the core network entities and the radio access network entities (see for example 3GPP TR 25.912, “Feasibility study for evolved Universal Terrestrial Radio Access (UTRA) and Universal Terrestrial Radio Access Network (UTRAN)”, version 7.0.0, incorporated herein by reference).
Traditionally (also in the currently discussed 3GPP SAE/LTE systems, see for example 3GPP TR 23.882 “3GPP System Architecture Evolution: Report on Technical Options and Conclusions”, version 1.8.0, February 2007 (incorporated herein by reference) the cellular networks are split into a control plane (also denoted C-plane) handling all control information and procedures and a user plane (also denoted U-Plane) handling the actual user data traffic, which also applies for the multicast architecture.
It may be assumed for exemplary purposes that the multicast control plane can be handled by all core network control plane entities, which are assigned to the mobile terminals during network attachment or mobility.
FIG. 1 shows an exemplary overview of an heterogeneous communication system, a part of which is a 2G/3G system and the other part being a 4G or SAE/LTE system. With reference to FIG. 1 the basic structure of SAE/LTE system will be described in further detail.
In a SAE/LTE system, the Mobility Management Entity (MME) 105 may be assumed to perform the core network control plane functionality, including mobility management. Some or all MMEs in a SAE/LTE system may also contain multicast management functionality and may be referred to as a Multicast-MME (M-MME).
On the other hand, for the SAE/LTE system the core network user plane functionality is contained in the User Plane Entity (UPE) 106. UPEs that are provided with user plane functionality for a multicast service may be referred to as a Multicast-UPE (M-UPE), if it is selected by an M-MME to handle the multicast service data in the SAE/LTE system.
Further in a SAE/LTE system, the Inter Access System Anchor (IASA) 109 may be assumed to anchor the user plane for mobility between the 2G/3G access system and the LTE access system. It therefore interfaces on the one hand to the entities of the SAE/LTE system like MME 106 and UPE 107 and on the other hand to the entities of the 2G/3G system like SGSN 102. For the latter the IASA, being part of the SAE/LTE system, may act like a GGSN. Further, the IASA may be assumed to provide access external networks, for example an operator's service network containing the BM-SC 101.
All entities mentioned above are considered to be logic entities providing specific functionality. These entities may be combined or separated in different nodes. For example the function of IASA providing access to external networks might be referred to as PDN SAE GW, while the function providing mobility anchor between 2G/3G access systems and LTE access systems might be referred to as Serving SAE GW. It might be further possible that the UPE 107 functionality is also comprised in Serving SAE GW.
Mobility Support and Operational States of Mobile Terminals
One important aspect for mobile communications in cellular networks is the optimized utilization of resources. This includes most importantly radio and network resources but also comprises mobile terminal resources like battery consumption. Several dedicated procedures and solutions exist to optimize this aspect. Usually cellular networks support different activity states of the mobile terminal, typically called active and idle mode (or state). There might even exist further sub-states. Each state poses different requirements to the system, e.g. different mobility mechanisms are applied, resulting in different utilization of resources.
For example a mobile terminal would transit to an active state, when it is engaged in an active communication session, i.e. is currently sending and/or receiving information. In UMTS systems a mobile terminal is said to be in active state if it maintains an RRC (Radio Resource Control) connection to the access network.
In active state the mobile terminal is usually known on a radio cell level by the network. Accordingly, each time the current cell of a terminal changes the mobile terminal will update its location in the network. This enables fast mobility procedures supporting highly mobile terminals while reducing (eliminating) losses caused by the mobility.
However, in order to achieve this, a lot of signaling messages have to be exchanged between the mobile terminal and the network and also within the network. Apparently this consumes considerable resources on the air interface, in the network and also in the mobile terminal.
Because of the above, when the mobile terminal currently does not maintain active communication channels, it might transit to an idle state, which is used in order to reduce the consumed resources. In this state the mobile terminal is usually only known on a larger area possibly comprising several cells, typically called routing area (RA), location area (LA) or tracking area (TA)—please note that these terms are considered interchangeable herein. Only when the current area of a terminal changes, it is required to update its location in the network. Further, only entities in the core network (CN) might be aware of the mobile terminal and mobility might be performed transparently to the entities of the radio access network (RAN). For example in 3G systems the mobile terminal is only known on the routing area/tracking area/location area-level when in idle state. For the currently developed SAE/LTE systems the mobile terminal's location in idle state is for example only known to the core network nodes implementing the MME.
In comparison to the active state, the idle state involves less signaling messages and location updates occur less frequently, therefore reducing the consumed resources on the air interface, in the network and also in the mobile terminal.
One concept in the development of 3GPP-based systems is the concept of having tracking areas (TAs). The target of this concept is to limit the amount of signaling (e.g. resulting from mobility) and required context information stored in the network for user equipments in the so-called idle state (or idle mode). The tracking area comprises a number of access nodes (base stations), within which the mobile terminals in idle states can move without the need to update their location at the core network entities. In 3GPP TR R3.018 “Evolved UTRA and UTRAN; Radio Access Architecture and Interfaces”, version 0.7.0 (incorporated herein by reference) two alternative tracking area concepts exist: overlapping tracking area and multi-tracking registration.
Regarding overlapping tracking areas an access node of the radio access network (e.g. eNodeB) is assigned to one or more tracking areas, i.e. might broadcast multiple tracking area identifiers (TA-IDs) in its cells. Using this concept a mobile terminal is always assigned to a single tracking area. The mobile terminal may update its location at the core network entities only in case it selects an eNodeB that does not broadcast its current TA-ID.
Regarding multi-TA registration an eNodeB is always assigned to a single tracking area, i.e. broadcasts only a single TA-ID in its cells. Using this concept a mobile terminal could be assigned to multiple tracking areas in parallel. In this case the mobile terminal updates its location at the core network entities, when it selects an eNodeB that does not broadcast any of the TA-IDs the mobile terminal is currently assigned to.
The typical mobility procedures used in the idle state are based on the mobile terminal, e.g. cell selection or cell re-selection. That is the mobile terminal decides, e.g. based on strength of received radio signal, which cell it selects, i.e. to which cell it tunes its receiver. As the tracking areas used in the idle state might span over several radio cells, a mobile terminal could be located at the edge of such an area, i.e. close to the border of one or more different areas. In such a case it might happen that due to changing radio conditions a mobile terminal might frequently select a cell belonging to a different area. Apparently this would also result in frequently required location updates of the terminal, alleviating the resource savings achieved by the idle state.
Above described conditions can occur in several situations. One example, described previously, is that a mobile terminal is located at the border of an idle state mobility area, e.g. routing area or tracking area. A similar situation might arise for a dual-mode terminal that switches based on radio conditions between different supported radio access technologies (RATs). For example considering a cellular communication system as standardised in 3GPP, an operator could deploy in addition to existing UMTS (2G and 3G systems) coverage cells utilizing an SAE/LTE compliant radio access (referred to as 4G or LTE systems), resulting in overlapping coverage of both radio access technologies. In such a scenario, a UMTS/LTE dual-mode terminal might select based on radio reception conditions either a UMTS cell or a LTE cell. As different network (control) entities are responsible for handling the mobile terminal depending on the utilised radio access technology, a location update is required each time the UE selects a cell of a different radio access technology.
Several options exist how to cope with this problem described above. One option is to establish some kind of hysteresis in order to reduce the occasions where a location update is required. For example this could be achieved by deploying overlapping idle state mobility areas. In this option a single cell might belong to multiple areas. Once a mobile terminal selected a cell of a different area its location is updated. If the mobile terminal subsequently selects the previous cell again no further location update is required, as this cell would also belong to the current idle state mobility area of the terminal. Another option is to allow the mobile terminal to be registered to multiple areas simultaneously. Only when it moves to an area that it is currently not registered to, a update of the mobile terminal's location would be required.
The latter concept can also be applied to the overlapping radio access technology coverage scenario discussed above. For example, as discussed in 3GPP TR 23.882, a mobile terminal in idle state might be registered to different tracking areas of UTRAN and E-UTRAN simultaneously. As long as it does not change its assigned routing area or tracking area, the terminal might move between the systems without any signaling to the network.
MBMS Service Provision in Heterogeneous Networks
Assuming a cellular communication system as specified in 3GPP comprising several radio access technologies (heterogeneous network), e.g, UTRAN (2G/3G) and E-UTRAN (SAE/LTE), it might apply above-mentioned concept to limit required signaling of a mobile terminal in idle state that is transiting between the different radio access technologies. As mentioned before, in each radio access technology different network (control) entities are responsible for handling the terminal. When the terminal is present in an access network, e.g. E-UTRAN, the respective network (control) entity maintains some context information for that terminal. In a normal case, when the terminal is no longer present, e.g. because it moved to a different access network, this context information would be deleted. However, assuming utilization of this concept for limiting required idle mode signaling, even when the terminal is no longer present in the access system, its context information might still be maintained by the responsible network (control) entity. As described in 3GPP TR 25.813 “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTR.AN); Radio interface protocol aspects”, version 7.1.0, September 2006 (incorporated herein by reference), same applies to the context information maintained in the mobile terminal itself. Here the configuration used in the previous radio access technology might be stored as part of the context information established in the new radio access technology.
A mobile terminal in idle state does not maintain any communication channels with the network and it might handle mobility by its own without any signaling. Of course this may lead to error conditions where the network assumes the presence of the mobile terminal in its network while it is actually no longer there. This might happen when, for example, the terminal goes out of radio coverage or due to some terminal failure, e.g. empty battery. In order to avoid such situations, typically some timers are used in the network and in the terminals. Before expiration of a timer the mobile terminal is required to update its location, even if it has not moved at all. This procedure is usually called periodic location update. In case the timer would expire without a location update from the UE, the network assumes that the UE is no longer present and deletes corresponding context information. Same applies to the mobile terminal. Also here the context information is no longer valid when no successful location update was performed before expiration of the timer. Typically the values of such periodic update timers are in the order of minutes, for example in UTRAN the default value is 30 minutes (see 3GPP, TS 25.331 “Radio Resource Control (RRC); Protocol Specification”, chapter 10.3.3.43, version 7.3.0, December 2006 (incorporated herein by reference).
With respect to above-mentioned concept for limiting the required idle mode signaling this means that a network (control) entity handling a mobile terminal in idle state might maintain corresponding context information even when the terminal is no longer present in the respective access network, until the periodic update timer expires, which could be in the order of minutes. Regarding unicast services this does not pose a problem, as a mobile terminal in idle state does not maintain active communication, i.e. no data is currently sent or received in the unicast service. However, for multicast services the situation might be different. For example considering MBMS services as specified in 3GPP, service reception for terminals in idle state is required as outlined in 3GP, 25.346 “Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access Network (RAN); Stage 2”, version 7.2.0, September 2006 (incorporated herein by reference). This means that there might be an active communication channel, at least in the downlink direction, maintained even in case only terminals in idle state are present.
Assuming a multicast service distributed in cellular communication system as specified in 3GPP comprising several radio access technologies, e.g. UTRAN and E-UTRAN, the following scenario could exist, which is also depicted in FIG. 2. A mobile terminal 105 that previously has activated 201 the multicast service is transiting to idle state in it current access network. The context information maintained by the responsible network (control) entity additionally comprises information about the activated multicast service. In this state the terminal changes the access system, e.g. selects an E-UTRAN cell while previously using an UTRAN cell. In case this change of radio access technology happens for the first time, the terminal has to register 202 in the new access system, e.g. by sending a tracking area update (that comprises an identification of the old UTRAN tracking area TA ID2G/3G), which will also cause transfer 203 of corresponding context information from the old network (control) entity (SGSN 102) to the current responsible one (MME 105). In case the multicast service is currently not being provided the new radio access technology, the new network control entity registers 204 for receiving the service at IASA 109 and finally the multicast U-plane is established 205 in the new radio access technology so that the service is also provided 206 therein.
When utilizing the concept of limited signaling for idle mode mobility, subsequently the mobile terminal might move between the different access systems without any signaling to the network, as long as the service is provided in the target cell and it belongs to current registered mobility area in the respective access system.
While in above scenario reception of the multicast service at the mobile terminal is possible independent of the currently selected access system, it might lead to inefficient utilization of network and radio resources. In case the mobile terminal remains camped on target access system, for example E-UTRAN, corresponding context in the network control entity handling the terminal in the other access system, e.g. UTRAN, remains valid until the periodic update timer expires or the terminal moves to a different mobility area in target system. As mentioned above the periodic update timer typically is in the order of minutes, i.e. if the terminal remains stationary (or at least within the assigned mobility area), its context in the old access system will remain valid for a possibly long time. In case the terminal was the only one in the old access system or when other terminals in the old system are leaving the service, e.g. due to mobility, the multicast service will constantly be provided until the periodic update time expires. This would of course unnecessarily consume network and particularly radio resources. This is especially wasteful for access systems where multicast transmissions consume much of the radio capacity, like it is the case in UTRAN.
Though in the examples of FIG. 1 and FIG. 2 above a heterogeneous network has been assumed essentially the same considerations apply in homogenous networks where a single radio access technology is utilized (e.g. mobile terminals in idle mode and receiving an MBMS service in a SAE/LTE system while moving through different tracking areas without deregistration from their respective previous tracking area).
As has been outlined above there are several potential problems and demands when mobile terminal mobility is provided for idle mode which are even worse if mobile terminals may register to multiple tracking areas simultaneously:                Network control entities might be unaware that a mobile terminal in idle state for which they maintain a valid context is no longer present in their access system        As long as the mobile terminal does not change registered routing area/tracking area, the currently selected access system might be unknown to the network        Signaling required for mobility idle state has to be limited as much as possible        